\section{Introduction} \label{sec:introduction}
Policy-based sofware systems are based on services whose execution is regulated by an access control policy that controls subject access
 to system resources. Several access control models such as RBAC, MAC, DAC and OrBAC \cite{dac,mac,rbac,orbac} may be used to specify access control policies. 
Managing conformance of a software system with respect to an access control policy that evolves over time is becoming a key issue for nowadays information systems. One of the difficulties 
related to such management is the alignment of the specified access control policy with the implementation.
 

When dealing with existing systems, such as legacy systems, the access control policy is assumed to be reconfigurable, and the code is supposed to be aligned accordingly. 
This ideal vision implies maintaining a clear traceability between what is stated by the policy and the internal security mechanisms enforcing this policy in the code. 
The main focus of this paper is to locate access control mechanisms in the code when this traceability is not ensured anymore 
to ensure secure evolution of the access control policies.

To make access controls easily reconfigurable, the recommended standard architecture is based on the separation of the policy decision point (PDP), the security component
 where access decisions are taken, and the policy enforcement points (PEPs), the security mechanisms inside the business logic where access is controlled. More precisely, 
after an access request, a PEP queries the PDP. The PDP decides whether this access should be allowed or not. The PEP then enforces the decision taken by the PDP. 
This separation enables an easy update and evolution of the policy since changes made to the policy in the PDP are directly reflected in policy enforcement at the PEP. 
This PEP-PDP paradigm thus makes the system more flexible and simplifies policy evolution. 

However, in practice the implementation of the software systems does not always conform to this model. 
In \cite{legacy}, we have studied this flexibility hypothesis in details for legacy code. The results showed that the legacy code often contains hidden security 
mechanisms, i.e. internal code or structural constraints that may restrict possible evolutions of the access control policy. We have also assumed that the PEPs are
 visible, documented and located inside the code. However, this assumption is not always realistic. For large systems, the PEPs are scattered in several places inside the 
code, the modules and the components of the system. Moreover, there is often no documentation about the functions nor about the exact locations of the functions/procedures where
 PEPs are included. This compromises system maintenance and secure evolution of the access policy governing the system.

In this paper, we study the identification and the mapping between accesses which may need to be regulated in an application and the PEPs inside the application code which may be used to control them. 
This is highly desirable for two main reasons. First, locating PEPs simplifies system
 maintenance and provides more information about the implementation of security mechanisms in the code. Consequently, when an access control issue is discovered, developers 
can easily map the problem to the related PEP to resolve the problem. 
Second, the mapping between security rules and PEPs in the application code which enforce them enables to ensure that when the specified policy is modified, the PEPs 
implemented in the application code are able to correctly enforce the new policy. 

To identify the PEPs inside the code, this paper presents an approach which involves two steps. First, we use static code analysis in order to identify accesses which can 
be made from within the application. In particular, we consider the analysis of the application class diagram to determine the different accesses which may need to be regulated 
by  the access control policy rules. This analysis also allows us to detect potentially misspecified policy rules or errors in the application's model. The second step aims at locating 
the PEPs inside the application code for every identified possible access. For this purpose, we consider the use of dynamic analysis. In particular, we combine the execution of 
test cases exercising each selected access control rule with mutation of policy rules. This technique generates two traces which differ at the location of the PEP in the trace. 
Thus, this technique determines the location of the PEP and enables its mapping to the accesses that it controls.


%The importance of access control is in continuous growth in the domain of IT security to prevent information from unauthorized access and to control users rights. In the last decades, a lot of access control models like Discretionary Access Control (DAC) \cite{dac}, Mandatory Access Control (MAC) \cite{mac}\cite{mac1}, Role Based Access Control (RBAC) \cite{rbac}\cite{rbac1},  Organization Based Access Control (ORBAC) \cite{orbac} have appeared in the literature. Access control policies are implemented using one of those models to define responses provided by an access control system to an access request. Today's access control architectures tend to have an implemented access control policy which is externalized from the business logic \cite{separationPEPPDP}. This design choice is advocated mainly by the following reasons. First: An access control policy is a subject to a continuous update, so it is always easier to update the policy when it is designed separately from the application code. Second: Separating the access control policy from application enables to avoid application errors that may be scattered across the application code.
%Due to the intricate design of organizations and the permanent update of its internal policies, the number of access control rules is in continuous increase. At the decision making time, the evaluation of a huge number of access rules may degrade performance in decision making, slow down the system response and negatively impact organization's revenues and profits. In this paper we target performance issues in access control policies evaluation, and propose an approach that aims at reducing the number of access rules that have to be considered at the evaluation time. At first level, we propose to reduce the number of rules with regards to the internal policy embedded in the application. Secondly, we propose to associate each PEP to a set of rules so that each evaluation process will involve only the evaluation of a set of access control rules instead of the global policy. To establish the mapping between a given PEP and a set of rules, we use the mutation testing framework presented in \cite{mutation}. We implement security tests that cover all the rules in the policy and enable to detect failures in the implemented security mechanisms. We apply mutation testing on access control policies by introducing mutation operators on access control rules and track the differences between tests execution considering an original access control policy and a mutated one. Comparing the execution pathes between a non mutated policy and mutated one enables to locate for every mutated rule its associated PEP. A lot of recent research has been focused on optimizing the decision making process \cite{Kolovski1} \cite{Xengine} \cite{Miseldine} \cite{clustering} \cite{decomposition}, however to the best of our knowledge, our approach is the first initiative that aims at optimizing the evaluation time considering the application implementation. 

The remainder of this paper is organized as follows: Section~\ref{sec:context} introduces the context of this work. Section~\ref{sec:approach} presents 
the overall approach. Section~\ref{sec:experiments} presents the main results. Section~\ref{sec:conclusion} discusses related work and concludes the paper.

